This invention relates generally to the field of software and, more particularly, to gathering and receiving a large number of failure reports about an application program module from a large number of users, and even more particularly, to a conversation between the user""s computer and a repository for reporting the failures.
When a computer program is being developed, developers sometimes find errors in the computer program. Errors, commonly referred to as xe2x80x9cbugsxe2x80x9d, can cause a computer executing the computer program to fail or xe2x80x9ccrashxe2x80x9d. If a computer program is publicly released with one or more errors, the time and costs associated with fixing the errors or xe2x80x9cbugsxe2x80x9d after release is extremely expensive. In order to fix these errors, developers must locate. the errors. In early stages of development, developers may want to prioritize the work in fixing the errors. Therefore, a frequency count can be made of the errors to track the number of times a particular error is encountered. There is a need for a system and method to track and count errors in a computer program while the program is being developed.
Generally, when a computer program is publicly released, users experience a high rate of problems during the first few weeks after public release. In many cases, users will contact the program manufacturer for technical assistance in resolving the problem. During this time, the program manufacturer experiences numerous user technical assistance queries. Technical assistance queries are very expensive and time consuming for users and for the program manufacturer.
Client-server networks can handle user queries for information as an alternative to technical assistance personnel. Typically, a server connects to one or more clients. One or more users interact with the clients to exchange queries for information. The server executes a computer program such as a database to handle consumers"" queries for information. When one or more clients contact the server for information, a query for each client is processed by the computer program executing on the server. However, this type of query processing is also very time consuming and expensive.
When a large number of clients query the server for information, the server may become overloaded when too many queries are requested of the server. Server operation may become extremely slow or sometimes the server may xe2x80x9ccrashxe2x80x9d due to sheer number of queries. Slow server operation and downtime for the server becomes extremely time consuming, expensive, and very frustrating for users.
Thus, there is a need in the art for an improved method and system for handling the location of errors or xe2x80x9cbugsxe2x80x9d in a computer program during program development.
There is a further need for an improved method and system for handling technical assistance queries from a large number of users after program release.
There is yet a further need for an improved method and system for handling error queries from a large number of clients.
The present invention meets the needs described above in a system and method for handling reporting of failures of a computer program. The present invention is able to quickly and efficiently handle reporting of failures from a large number of users.
A preferred embodiment of the present invention is included in the xe2x80x9cOFFICExe2x80x9d suite of application program modules, also manufactured, distributed, and sold by Microsoft Corporation. The invention can also be used in conjunction with the xe2x80x9cINTERNET EXPLORERxe2x80x9d web browser application program module, manufactured, distributed, and sold by Microsoft Corporation of Redmond, Wash. When a program module experiences a failure, failure information is reported to a repository by a failure reporting executable.
A failure may be a crash of the program module or a set-up failure during installation of the program module. Additionally, the failure may be a problem encountered during in-house testing of the program module. Once detected, program failures may be reported directly to a repository, such as a server operated by the manufacturer of the program that failed. The repository may also be a local file server operated by the corporation. For example, the corporate file server repository may be used to store the failures encountered by users in a corporate environment until these failures may be reported to the software manufacturer""s server.
The present invention provides a network conversation between a failure reporting executable and a server that permits the handling of a large number of failure reports quickly and efficiently. In one stage of the network conversation, a relatively lightweight communication is used to rapidly determine whether a particular failure has been previously encountered. If a particular failure has been previously encountered, the server returns information relating to the particular failure, otherwise the next stage of the network conversation is initiated. In the next stage of the network conversation, a more complex communication is used to determine whether a particular failure has been encountered and what action should be taken. Typically, a request for additional failure information is sent from the server to the failure reporting executable. During the next stage of the network conversation, the additional failure information is collected by the failure reporting executable and sent to the server. In the last stage of the network conversation, the failure reporting executable informs the server that the information has been sent.
More particularly described, when program failures are reported to the repository, a four stage network conversation is implemented to handle the expected scale and volume of failure reports. In stage one, a failure reporting executable creates a static HTML string address with failure information. The failure reporting executable determines whether the string address matches a predefined string address at the repository. In response to determining that the string address matches a predefined string address at the repository, the repository sends file content (located at the matching string address) to the failure reporting executable. If no matching string address is found, stage two of the network conversation is initiated.
Stage two of the network conversation begins when the failure reporting executable creates an active server page (ASP) record query with failure information. The failure reporting executable accesses the repository to search a set of predefined failure records, such as SQL server records, and the repository determines whether the record query matches a predefined failure record. In response to determining that the record query does not match a predefined failure record, the repository starts a preset counter for tracking needed additional failure information requests. The repository then creates a failure record with failure information corresponding to the record query, and sends a request for additional failure information to the failure reporting executable.
In response to determining that the record query matches a failure record, the repository determines whether the preset counter is greater than zero. In response to determining that the preset counter is greater than zero, the repository sends a request for additional failure information to the application program module. Stage two of the network conversation ends when the request for additional failure information is sent to the failure reporting executable. Stage three of the network conversation is initiated when the failure reporting executable sends the additional failure information to the repository. Stage four of the network conversation is initiated when the failure reporting executable informs the repository of the successful transfer of additional failure information from the failure reporting executable to the repository. The repository then decrements the preset counter, and determines whether the preset counter is greater than zero. In response to determining the preset counter is zero, the repository creates a static HTML string address corresponding to the record query. In response to determining that preset counter is greater than zero, the repository ends stage four of the network conversation.